All the Perl that's Practical to Extract and Report

Dan Bricklin's wikiCalc: Webs of Spreadsheets

Mark Leighton Fisher on 2006-04-28T16:58:02

The latest project of Dan Bricklin (the inventor of VisiCalc) is wikiCalc, a browser-based collaborative spreadsheet using the familiar spreadsheet UI model. wikiCalc's goals are:

  • Easy tabular data input by using the familiar spreadsheet UI – modern organizations live and die by spreadsheet data;
  • Collaboration by incorporating a cell-level version-control system. Excel supports limited shared spreadsheets, but even those are designed for one person per spreadsheet "check-outs". wikiCalc would allow, for example, a whole department to edit parts of a spreadsheet at the same time;
  • Use of a wide range of data types including numbers, text, formulas, HTML, Wiki markup, and (eventually) live data retrieval from the Web;
  • Saving spreadsheets as native files and/or to a Web page;
  • Portability on the front end by using a web browser GUI. For ease of use, wikiCalc uses AJAX for more immediate feedback (up/down/left/right cell navigation, automatic recalc, automatic per-cell data saving, et.al.); and
  • Portability on the back end by building it in Perl, such that
    • On the desktop, wikiCalc runs on an embedded webserver; and
    • On the network, wikiCalc runs on a network webserver.

Well, why not just enter your data into a database? I mean, that's what databases are for, right? Contemporary multi-user databases have an important, yet often-overlooked difference from spreadsheets – scalar values (1 field/column in 1 row) are early-bound in databases, but late-bound in spreadsheets ("Databases are like Java, but spreadsheets are like Perl"). In other words, spreadsheet users don't have to care about the details of the data in their cells until they have to manipulate that data. If the data in a cell is never used by a formula, the user doesn't have to care about whether that data is properly formatted as a particular member of the necessarily limited set of available datatypes. This makes creating spreadsheets easier for the average person.

Contemporary multi-user databases, on the other hand, demand that you plan in advance for the type of each and every field/column in the database. This is a large requirement for many people, most of whom are not even aware that different lengths of text may require different database field/column types (BLOBs, anyone?)

It would be instructive to know how many spreadsheets vs. how many databases are created by people each year. My hunch is 10X-100X (or more) spreadsheets are created than databases, in part due to the late-binding of data types in spreadsheets. For smaller sets of data, spreadsheets are simply easier. This comes from someone comfortable with databases – Oracle, PostgreSQL, MySQL, and Access are a regular part of my toolbox, I've been a PostgreSQL tuning expert on a consulting job, and I've written database program code at a database vendor. With all that database experience, I still create many, many more spreadsheets than databases each year.

The pieces of wikiCalc have been in place for several years, but it took Dan Bricklin to combine them. wikiCalc's combination of features expands the spreadsheet metaphor: easy entry of tabular data for the Web, multi-user spreadsheets (per-cell version control), and spreadsheet portability across multiple platforms among others. As someone who seeks out novel feature combinations (coming up with a few of my own novel feature combinations), I am genuinely excited to see the power that this set of features will provide. Uses yet undreamt-of will be unleashed – wikiCalc is a fine example of innovation at work.

Tags: , , , ,